feat: calculate taskbar position and display on top of it #125
Conversation
|
Does this account for opening it from the tray overflow? e.g. from: EDIT: The Logitech app I use does this actually, I don't think I like it What are the downsides of doing it on the cursor position? |
|
My idea was to actually draw it from the taskbar because otherwise it just leaves the tray window floating on your desktop. I clicked this one from the expanded overflow and it painted like this: |
|
|
||
| // Adjust if the window goes off the right edge of the display. | ||
| if (x + width > workArea.X + workArea.Width) x = workArea.X + workArea.Width - width; | ||
| int x, y; |
There was a problem hiding this comment.
The previous calculations had some hardcoded plus or minus 10 as a padding, shouldn't we do something similar to avoid it directly touching the taskbar or the side of the screen?
| case TaskbarPosition.Bottom when tb.AutoHide: | ||
| // Auto-hide bottom bar sits under the workArea – use workArea, not bounds. | ||
| x = workArea.X + workArea.Width - panelSize.Width; | ||
| y = workArea.Y + workArea.Height - panelSize.Height - tb.Gap; | ||
| break; | ||
|
|
||
| // Adjust if the window goes off the top edge of the display (somehow). | ||
| if (y < workArea.Y) y = workArea.Y; | ||
| default: // right or bottom when not auto-hiding | ||
| x = workArea.X + workArea.Width - panelSize.Width; | ||
| y = bounds.Y + bounds.Height - panelSize.Height - tb.Gap; | ||
| break; |
There was a problem hiding this comment.
I don't get why we wouldn't just always use workArea.Height here, the comment doesn't do a very good job explaining why we wouldn't prefer to always use the workArea.Height.
| @@ -338,4 +317,70 @@ public struct POINT | |||
| public int Y; | |||
| } | |||
| } | |||
Closes: #119